終於到了最後一天，在開發 Flutter 程式的過程中，少不了寫測試來確保程式正常運作，通過三十天的分享，除了可以將過去開發過程中碰到的問題與解法分享給大家之外，也能通過寫作，能更深入探索之前沒想到細節。

尚未提及的部分

在這三十天中，我們講了很多單元測試與 Widget Test 的技巧，也談論了很多測試相關的心法。但是這些都只是滄海一粟，還有很多沒有談論到的議題，例如：Flutter 的 Integration Test 該怎麼寫、如何在 CI/CD 執行測試並回報錯誤，或者是如何用 Firebase Test Lab 來讓測試跑在雲端設備上，這些都是在落實測試到專案上可能會碰到的問題。

除了工具的使用之外，寫測試也與實例化需求息息相關，當我們在拆解需求時，可以使用實例化需求來減少不同角色對於需求的認知差距，而這些實例化需求例子也是十分適合拿來衍生測試案例。

由於 Flutter 還算是比較新的框架，相關的學習資源還是比較多在網路上，若想學習更多 Flutter 相關的之是，可以參考Flutter 的 Youtube 官方頻道或 Codelab。

邁向職業工程師

就像在職業運動領域中，職業運動選手除了領薪水上場打球之外，會在平常通過各種訓練提升球技，才能在競爭激烈的球場上脫穎而出。同樣的，如果我們想成為更好的工程師，也應該向職業運動選手，平時就要練習尚未熟練的技術，無論是框架使用，重構或者測試都是技術，很難只看過一次文章，上過一次課就能熟練的運用在實務上的，而是需要透過不斷的刻意練習與思考，重複的犯錯與調整，才能在實務上熟練使用。

沒有對錯

隨著電腦速度越來越快與 AI 工具的出現，許多以前的我們熟知的方式可能在未來有更好的方式，像是我們能用 welltested 來幫忙產生測試，那是不是一些簡單的情境，我們可以用 AI 來幫忙測試就好？或者是以 Widget Test 來說，以前 UI 相關的測試運起來可能都會不穩定，但是現在 Widget Test 寫起來也不麻煩，那 Widget Test 的數量是不是能比單元測試多了呢？

我們可以多方的嘗試不同的作法，然後頻繁的檢視結果，看看是否做法能有效解決問題，有沒有縮短開發時間，有沒有減少 Bug 數量。當然發現沒用的話，我們就得馬上調整採用其他做法了。透過一次一次的迭代，我們的開發也會越來越順暢，以小步快跑的節奏，小範圍的調整，然後回顧解法是否有效，有效則繼續，無效則馬上換個方法，持續優化整個開發流程。

感謝我的好同事

能完成三十天的鐵人賽文章，特別感謝我的好同事們，透過 Pair Programming 與 Code Reivew，除了提高產出的品質之外，也能在開發過程中與夥伴互相學習，有句話說「一個人可以走得很快，一群人可以走得很遠。」，如果想要持續進步，除了自己努力之外，有志同道合的夥伴也是很重要的，其中特別推薦優質同事的粉絲團 Kuma的軟體工程murmur集，有興趣的朋友也可以按讚訂閱加分享起來 XD。

最後

無論是手動測試或自動化測試，再交付產出之前，我們都必須想辦法確保我們是在交付價值，而不是交付垃圾。我們很難寫一寫完程式後，程式就直接是最好的狀態，更多的是需要用測試確保功能沒有問題，支持後續的重構與功能調整。感謝三十天持續追蹤的觀眾朋友們，也歡迎有興趣的朋友追蹤我的 Medium，未來也會持續分享許多 Flutter 開發上的的技巧。